개요

쿠버네티스 스토리지에는 재귀적 읽기 전용 마운팅에 대한 내용이 나온다.
그러나 처음에 헷갈렸던 게, 파드에서 서브 디렉토리를 볼륨으로 만들고 이걸 쓰기 가능하게 마운팅하면 문제가 생긴다는 것으로 이해를 했었다.
그러나 구체적으로 이것은 읽기 전용 마운팅을 했는데, 외부에서 해당 디렉토리의 서브로 마운팅을 한 상황을 이야기한다.
구체적으로 이게 무엇을 뜻하는지 알아보자.

실험 환경은 EKS 1.31버전이다.

세팅

먼저 노드에 이렇게 디렉토리가 잡혀있다고 해보자.

apiVersion: v1
kind: Pod
metadata:
  name: recursive
spec:
  containers:
  - name: recursive
    image: centos
    command: ["sh", "-c", "while true; do sleep 60; done"]
    volumeMounts:
    - name: first
      mountPath: /test/readonly
      readOnly: true
      # recursiveReadOnly: Enabled
  volumes:
    - name: first
      hostPath:
        path: /test/readonly
  terminationGracePeriodSeconds: 1

이 파드는 readonly라는 디렉토리를 읽기 모드로 마운팅하고 있다.
그렇기에 기본적으로 해당 디렉토리에 쓰기 작업을 할 수는 없다.
그러나 스토리지 공간 부족 등의 이유로 관리자가 노드를 관리하면서 submount 디렉토리에 다른 디렉토리를 마운팅하여 사용한다고 쳐보자.

간단한 테스트를 위해 바인딩을 했다.
그러나 실제 상황이라면 nfs나, tmpfs를 마운팅하는 등의 조작을 할 수 있을 것이다.
원래 파드 스펙의 의도대로라면, 파드는 submount 디렉토리에 쓰기 작업을 할 수 없어야만 한다.

결과..

그러나.. 파드는 당당하게 해당 디렉토리에 쓰기 작업을 할 수 있게 된다.
관리자의 실수로 인해 임의의 사고가 발생할 수 있게 된다는 것이다.

결론

가장 좋은 예방책은, 애초에 hostPath를 사용하지 못하게 하는 것이다.
이는 어드미션 컨트롤을 통해 validation failed를 띄우도록 하는 것이 가장 효과적일 것이다.

문서의 내용대로라면, recursiveReadOnly: Enabled를 통해 이런 문제를 방지할 수 있다.^[1]
이 기능은 Kubernetes v1.31 - Elli에서부터 기본 true로 설정돼있어서 해당 필드를 넣어서 파드를 배포하면 파드가 잘 배치된다.

그러나 eks 1.31에서는 containerd의 버전이 2.0이 아니라, 해당 필드를 적용해도 아무런 소용이 없다..
일해라 aws

k get --raw /api/v1/nodes/노드/proxy/configz | jq '.kubeletconfig.featureGates'

또한 기본 활성화된다던 피처 게이트 역시 활성화되지 않은 것으로 보인다.
이건 아마 아직 해당 기능이 베타 상태이기에 이렇게 해둔 게 아닐까 싶기도 하다.

get으로 파드의 정보를 보더라도, 적용이 되지 않아 disabled된 것이 보인다.

번외 - 로컬 클러스터 테스트

내 로컬 클러스터는 1.32 버전이기 때문에 관련한 설정이 적용될 거라 생각한다.

같은 방식으로 세팅을 진행했는데, 이번에는 이렇게 에러가 나온다.
runtime에서 지원되지 않는다고 확실하게 말이 나오는 것이 보였다.

내 로컬 클러스터 버전도 낮은 버전이었다..
다만 해당 필드를 정확하게 인식하고 있다는 점에서 eks 클러스터와는 다른 모습이다.

관련 문서

참고